Question on colour/tint in 16bpp and 32bpp modes

discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

Hi all,

This week I've been extending the PiTubeDirect framebuffer to work better with 16bpp and 32bpp modes.

I have a question for the RISC OS folk....

I think I understand the background to TINT (VDU 23,17,0..3), i.e. why it was necessary for Acorn to introduce this ugly hack when transitioning from 64 to 256 colour technology, and that this is not now the preferred way of setting colours.

Beyond 256 colours, Acorn abandoned setting colours through the VDU interface, instead relying on the OS_SetColour and ColourTrans_SetGCOL APIs. Up until then, pretty much any graphical operation could be done with VDU codes, so I think the implications of this change are significant. For example, it would limit the effectiveness of second processors on the Archimedes/RISC PC architecture, if such a thing was ever imagined.

Anway, I'm trying to understand whether TINT actually works in >256 colour modes, giving some kind of compatibility to existing applications on higher bit-depth displays.

I've written the following test program:

Code: Select all

   10 MODE 640,512,32
   20 W=1280:H=128
   30 GCOL 0,16
   40 FOR T=3 TO 0 STEP -1
   50   Y=T*H
   60   TINT 2,64*T
   70   RECTANGLE FILL 0,Y,W,H
   80   PRINT ~POINT(0,Y),~TINT(0,Y),~VDU 153, ~VDU 157
   90 NEXT
The only RISCOS-like platform I have access which supports >256 colours is Matrix Brandy.

Martix Brandy in a 8-bpp mode:
Screenshot from 2021-09-10 14-52-51.png
Martix Brandy in a 32-bpp mode:
Screenshot from 2021-09-10 14-54-24.png
The results are slightly curious...

If anyone could try this program on an actual RISC OS system (real or emulated is fine), I would be very grateful.

I'm trying to understand:
- whether TINT works at all in 32-bpp modes
- whether the resulting colours are the same between 8-bpp and 32-bpp modes
- what values POINT and TINT return (i.e. OS_ReadPoint)
- what values the VDU current forground colour/tint variables hold during the test

Many thanks

Dave
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

hoglet wrote:
Fri Sep 10, 2021 3:19 pm
Beyond 256 colours, Acorn abandoned setting colours through the VDU interface, instead relying on the OS_SetColour and ColourTrans_SetGCOL APIs. Up until then, pretty much any graphical operation could be done with VDU codes, so I think the implications of this change are significant. For example, it would limit the effectiveness of second processors on the Archimedes/RISC PC architecture, if such a thing was ever imagined.
Slightly off-topic but you have hit a nerve...

Yes, a serious mistake in my opinion. Somehow (change of personnel?) Acorn forgot that the 'VDU stream' was not only crucial to the Dual Processor architecture but also enabled storing graphics 'macros' in strings or files. I've quite frequently used this technique to store a sequence of VDU commands in a string variable that you can then 'draw' using PRINT vdu$;.

It also has a direct impact on my BASICs (BBC BASIC for Windows and BBC BASIC for SDL 2.0) which, although not a true dual-processor architecture, rely on the VDU stream to serialise the graphics commands when sent from the interpreter thread to the GUI thread. So, although they (of course) support full 24bpp colours, they don't use TINT at all.

This is linked with confusion over the role of the palette. In Acorn systems the palette seems to be inextricably linked to the use of a colour look-up table in the display hardware (in the VidProc ULA in the BBC Micro) with the consequence that the 24bpp modes don't use a palette at all. But that's illogical: the analogy with an artist's palette shows you that it's perfectly sensible to use a palette with a 24bpp RGB display.

So my BASICs work how I think Acorn's systems should have worked. There is always a palette: in display modes which have a hardware colour look-up table it reflects the contents of that table but in RGB modes it's just a software look-up table that acts as an interface between a logical colour and a physical colour (interestingly, this dual use of the palette is identical in the design of Windows GDI).

Having to use the palette even in 24bpp modes is not a limitation, as some people assert, but actually aids compatibility; programs designed to run on a display with a hardware LUT can run without modification in an RGB mode (unless they rely on 'palette animation' of course). There is no limit on the number of colours that can be displayed at any one time.

It's a pity that by the time RGB displays were introduced and the TINT approach to extending the colour gamut devised, the BBC's influence over Acorn had all but evaporated. So even if I had realised what was being proposed (which I don't think I did until a lot later) we probably couldn't have persuaded Acorn to change course.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

Thanks for that response Richard.

I'm rather more restricted in my ability to change things, because the Native ARM Co Pro actually uses the Acorn ARM Basic (v1.35). So the PiTubeDirect VDU driver needs to work well with that, which means doing something sensible with the TINT command which uses VDU 23,17.

ARM Basic (v1.35) also includes:
- COLOUR OF r,g,b ON r,g,b
- COLOUR OF n ON n
( and similar GCOL variants)

The COLOUR OF n format is particularly wierd, because n is a "Colour Number" which is I think is the value written for the pixel in the frame buffer.

Yet as far as I can tell, ARM Basic provides to easy way to determine a valid n, where as Brandy has n=COLOUR(r,g,b). ARM Basic could easily have provided a similar wrapper to Colour Trans.

I also found this document describing Basic V, including the miriad of gcol/colour options:

Code: Select all

GCOL
Syntax: a) GCOL <colour expression>
	b) GCOL <colour expression> TINT <tint expression>
	c) GCOL <action expression> , <colour expression>
	d) GCOL <action expression> , <colour expression>
					TINT <tint expression>
	e) GCOL <red expression> , <green expression> ,
					<blue expression>
	f) GCOL OF <expression> ON <expression>
	g) GCOL OF <action expression>, <expression>
		 ON <action expression>, <expression>
	h) GCOL OF <red expression>, <green expression>,
		<blue expression> ON <red expression>,
		<green expression>, <blue expression>
	i) GCOL OF <action expression>, <red expression>, 
		<green expression>, <blue expression> 
		ON <action expression>, <red expression>,
		<green expression>, <blue expression>
I'm not sure of the origin of this or it's intended scope. It's shipped with Brandy, but the intro seem to imply it's more of a community effort to document ARM Basic V.

Coming from the 8-bit world, I find this mess all rather bemusing! It is sad that Acorn seems to have rather lost the plot at this point.

Dave
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

hoglet wrote:
Fri Sep 10, 2021 4:31 pm
I also found this document describing Basic V, including the miriad of gcol/colour options
Yes, it's a mess! The only thing my approach is not directly applicable to, currently, is 32bpp colour because the palette-setting VDU 19 command doesn't have a suitable variant, but that could easily be fudged (e.g. setting the high bit of the logical colour meaning the next 4 bytes are ARGB).
I'm rather more restricted in my ability to change things
Yes, I appreciate that and it's why I prefaced my comments with the Off Topic remark.
It is sad that Acorn seems to have rather lost the plot at this point.
Absolutely, and surprising. The interface between BASIC (or The Language in general) and the OS was messed up by this OS_SetColour and ColourTrans nonsense, and all (seemingly) because of a lack of realisation that one could still have a palette in 'non-paletted' display modes. :?
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

hoglet wrote:
Fri Sep 10, 2021 4:31 pm
ARM Basic (v1.35) also includes:
- COLOUR OF r,g,b ON r,g,b
- COLOUR OF n ON n
( and similar GCOL variants)
The COLOUR OF n format is particularly wierd, because n is a "Colour Number" which is I think is the value written for the pixel in the frame buffer.
Plus the semantics scream that it should be OFF not OF. HTF is 'OF' the complement to 'ON'???? Particularly as the function is to set the two colours of a flashing pair, what would be called the 'ON' colour and the 'OF'....????? colour?????
hoglet wrote:
Fri Sep 10, 2021 4:31 pm
I also found this document describing Basic V, including the miriad of gcol/colour options:

Code: Select all

GCOL
Syntax: a) GCOL <colour expression>
(snip)
Somewhere I'd documented what various COLOUR/TINT/GCOL commands issue in later ARM BASICs. Some of them don't go through the VDU driver. I'm sure it's somewhere on this machine. (rassen frassen windows-not-searching-files-with-no-extension-frassen).

The underlying structure of the COLOUR/TINT API is sound. COLOUR/GCOL specifies the top 6 bits of the colour number, TINT specifies the next 8 bits, theoretically allowing up to 2^14 colours to be selected as the active colour being used. It all falls down a bit when, possibly, loads of people not involved with the original clean engineering started throwing their pet wants into it, and the bodging up of the palette.

OF? OF?????

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

I've finally managed to setup rpcemu properly, thanks to the nice guide here:
https://www.4corn.co.uk/articles/rpcemu371win/index.php

I've had to change my test program somewhat, because RISCOS 3.70 comes with an older version of ARM Basic (1.16) which lacks the MODE w,h,d statement and the VDU function. So it's got a bit longer:

Code: Select all

   10 DIM block% 32
   20 block%!0=1
   30 block%!4=640
   40 block%!8=512
   50 block%!12=5
   60 block%!16=-1
   70 block%!20=-1
   80 SYS "OS_ScreenMode",0,block%
   90 W=1280:H=128
  100 GCOL 0,16
  110 FOR T=3 TO 0 STEP -1
  120 Y=T*H
  130 TINT 2,64*T
  140 RECTANGLE FILL 0,Y,W,H
  150 block%!0=153
  160 block%!4=157
  170 block%!8=-1
  180 SYS "OS_ReadVduVariables", block%, block%
  190 PRINT ~POINT(0,Y),~TINT(0,Y),~block%!0,~block%!4
  200 NEXT
Screenshot from 2021-09-11 10-55-12.png
So my conclusion from that is that the TINT statement does indeed work correctly in 32-bpp modes.

I was also interested to see what happened if I added a OS_SetColour to set the colour:

Code: Select all

   10 DIM block% 32
   20 block%!0=1
   30 block%!4=640
   40 block%!8=512
   50 block%!12=5
   60 block%!16=-1
   70 block%!20=-1
   80 SYS "OS_ScreenMode",0,block%
   90 W=1280:H=128
  100 GCOL 0,16
  110 FOR T=3 TO 0 STEP -1
  120 Y=T*H
  130 TINT 2,64*T
  140 SYS "OS_SetColour",0,&444444+&111111*T
  150 RECTANGLE FILL 0,Y,W,H
  160 block%!0=153
  170 block%!4=157
  180 block%!8=-1
  190 SYS "OS_ReadVduVariables", block%, block%
  200 PRINT ~POINT(0,Y),~TINT(0,Y),~block%!0,~block%!4
  210 NEXT
Screenshot from 2021-09-11 11-08-21.png
It seems that using this form of colour setting overrides simply overrides the colour/tint values (i.e. the foreground colour/tint VDU variables are not updated or invalidated, and retain their previous values)

I'll try to implement something similar in the PiTubeDirect VDU driver.

Dave
Last edited by hoglet on Sat Sep 11, 2021 11:22 am, edited 1 time in total.
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

jgharston wrote:
Sat Sep 11, 2021 11:12 am
Plus the semantics scream that it should be OFF not OF. HTF is 'OF' the complement to 'ON'???? Particularly as the function is to set the two colours of a flashing pair, what would be called the 'ON' colour and the 'OF'....????? colour?????
I think you are misunderstanding the intended semantics.

It's not ON/OFF as in flashing. OF means foreground and ON means background.

i.e. COLOUR OF 255,0,0 ON 0,0,255 mean set a text colour OF red ON a blue background.

I'm not defending it though!
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

jgharston wrote:
Sat Sep 11, 2021 11:12 am
The underlying structure of the COLOUR/TINT API is sound. COLOUR/GCOL specifies the top 6 bits of the colour number, TINT specifies the next 8 bits, theoretically allowing up to 2^14 colours to be selected...
It isn't "sound" if it cannot be represented by VDU commands, in my opinion.

With a palette (even in 'non-paletted' RGB modes) you can select up 2^24 colours with a potential for extension to 2^32, meaning that TINT isn't necessary at all and the VDU stream works again.

Because of the way the top bit of the logical colour number indicates foreground/background you are limited to a palette of 128 different colours (even if the underlying drivers support a 256-colour palette, which they do in my BASICs) but that's still plenty given that they can be reused.

If you want to pretend that there isn't a palette that's fine, just map COLOUR r,g,b to VDU 19,1,16,r,g,b,18,0,1 (which is actually two concatenated VDU commands but you don't need to know that) and everything will work the same as it does with OS_SetColour.

I know I can't turn back the clock, but I sure would like to!
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

Richard Russell wrote:
Sat Sep 11, 2021 12:11 pm
jgharston wrote:
Sat Sep 11, 2021 11:12 am
The underlying structure of the COLOUR/TINT API is sound. COLOUR/GCOL specifies the top 6 bits of the colour number, TINT specifies the next 8 bits, theoretically allowing up to 2^14 colours to be selected...
It isn't "sound" if it cannot be represented by VDU commands, in my opinion.
"sound" as in:

Code: Select all

colour number   cccccccccccccc
COLOUR        xxcccccc          (VDU 17 or 18)
TINT                  cccccccc  (VDU 23,17)
Agreed that once you go outside the VDU driver API, it breaks down.

I couldn't find my earlier notes, it ended up quicker re-doing the research and retyping them. At least I knew what I was looking for this time. ;)

Code: Select all

ARM BASIC VDU I/O
=================

TINT n,m         -> VDU 23,17,n,m,0,0,0,0,0,0


COLOUR n         -> VDU 17,n
COLOUR n TINT m  -> VDU 17,n, 23,17,n DIV 128,m,0,0,0,0,0,0
COLOUR l,p       -> VDU 19,l,p,p DIV &100,p DIV &10000,p DIV &1000000
COLOUR l,r,g,b   -> VDU 19,l,16,r,g,b
COLOUR l,r,g,b,s -> Palette,l AND 255,16,&bbggrrss,xx,Palette_Set

COLOUR r,g,b     -> ColourTrans_SetTextColour,&bbggrr00,xx,xx,&00
COLOUR OF,r,g,b  -> ColourTrans_SetTextColour,&bbggrr00,xx,xx,&00
         Select text foreground
COLOUR ON r,g,b  -> ColourTrans_SetTextColour,&bbggrr00,xx,xx,&80
         Select text background
COLOUR OF,r,g,b ON R,G,B
                 -> ColourTrans_SetTextColour,&bbggrr00,xx,xx,&00
                    ColourTrans_SetTextColour,&BBGGRR00,xx,xx,&80
         Select text foreground and background
    Selects the logical colour that is currently defined closest to R,G,B

COLOUR OF l      -> SYS OS_SetColour,&40,l
         Select logical colour l as text foreground
COLOUR ON l      -> SYS OS_SetColour,&50,l
         Select logical colour l as text background
COLOUR OF l ON m -> SYS OS_SetColour,&40,l SYS OS_SetColour,&50,m
         Select text foreground and background


GCOL n           -> VDU 18,0,n
GCOL k,n         -> VDU 18,k,n
GCOL n TINT m    -> VDU 18,0,n, 23,17,(n DIV 128)+2,m,0,0,0,0,0,0
GCOL k,n TINT m  -> VDU 18,k,n, 23,17,(n DIV 128)+3,m,0,0,0,0,0,0

GCOL r,g,b       -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,0
GCOL k,r,g,b     -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,k AND 255
GCOL OF r,g,b    -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,0
GCOL OF k,r,g,b  -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,k AND 255
          Select graphics foreground
GCOL ON r,g,b    -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&80,0
GCOL ON k,r,g,b  -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&80,k AND 255
          Select graphics background
GCOL OF r,g,b ON R,G,B
                 -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,0
                    ColourTrans_SetGCOL,&bbggrr00,xx,xx,&80,0
GCOL OF k,r,g,b ON R,G,B
                 -> ColourTrans_SetGCOL,&bbggrr00,xx,xx,&00,k AND 255
                    ColourTrans_SetGCOL,&bbggrr00,xx,xx,&80,k AND 255
         Select graphics foreground and background
    Select the logical colour that is currently defined closest to R,G,B

GCOL OF l?
GCOL ON l?
GCOL OF l ON l?

n=COLOUR(????)
n=GCOL(????)


[code]
colour number   cccccccccccccc
COLOUR        xxcccccc          (VDU 17 or 18)
TINT                  cccccccc  (VDU 23,17)
[/code]
I know I can't turn back the clock, but I sure would like to!
:)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

hoglet wrote:
Sat Sep 11, 2021 11:21 am
jgharston wrote:
Sat Sep 11, 2021 11:12 am
Plus the semantics scream that it should be OFF not OF. HTF is 'OF' the complement to 'ON'???? Particularly as the function is to set the two colours of a flashing pair, what would be called the 'ON' colour and the 'OF'....????? colour?????
I think you are misunderstanding the intended semantics.

It's not ON/OFF as in flashing. OF means foreground and ON means background.

i.e. COLOUR OF 255,0,0 ON 0,0,255 mean set a text colour OF red ON a blue background.

I'm not defending it though!
There was a nagging voices at the back of my head as I typed that. ;)
But even so. Eugh!

As COLOUR OF r,g,b is coded to be identical to and is dpescified as being identical to COLOUR r,g,b, I think if I was inventing it I'd have done COLOUR r,g,b {ON r,g,b} and just drop the OF prefix.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
BeebMaster
Posts: 4444
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by BeebMaster »

Couldn't do it on real RISC PC 700 with RISC OS 3.70. First version said syntax error (as predicted), or Screen mode not available if BASIC 1.35 loaded, and the same with the second version.

(If you take the BAS135 file that's built-in to the Native ARM Pi Tube and change the file type to Module, it will run on the RISC PC).
Image
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

BeebMaster wrote:
Sat Sep 11, 2021 3:04 pm
Couldn't do it on real RISC PC 700 with RISC OS 3.70. First version said syntax error (as predicted), or Screen mode not available if BASIC 1.35 loaded, and the same with the second version.
Do you have 2MB VRAM fitted?
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

jgharston wrote:
Sat Sep 11, 2021 2:03 pm
I think if I was inventing it I'd have done COLOUR r,g,b {ON r,g,b} and just drop the OF prefix.
That's legal as well, i.e. the OF keyword is very much optional.

As far as I know, only Brandy has

Code: Select all

red=COLOUR(255,0,0)
This value (a mode specific colour number) works for both text and graphics.

Nothing supports =GCOL(r,g,b) as it's unnecesary.

Dave
User avatar
BeebMaster
Posts: 4444
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by BeebMaster »

hoglet wrote:
Sat Sep 11, 2021 3:24 pm
BeebMaster wrote:
Sat Sep 11, 2021 3:04 pm
Couldn't do it on real RISC PC 700 with RISC OS 3.70. First version said syntax error (as predicted), or Screen mode not available if BASIC 1.35 loaded, and the same with the second version.
Do you have 2MB VRAM fitted?
Yes. Maybe it's something to do with the monitor definition file?
Image
User avatar
BeebMaster
Posts: 4444
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by BeebMaster »

I can get it to do MODE 320,256,32 if that helps:
Attachments
scrn0.png
Image
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

BeebMaster wrote:
Sat Sep 11, 2021 3:32 pm
I can get it to do MODE 320,256,32 if that helps
Thanks!

As well as the colour values, it shows the external x/y resolution is 640x512, which is unexpected (to me anyway)

I always thought with custom modes the XEigFactor would be YEigFactor chosen such that the logical resolution would be at least 1280x1024 (or some such minimum value). It looks like they are just being set to one here.

Is that defined somewhere?

I wonder if later versions of RISC OS behave the same as well? Time to dig out a spare Pi....

Dave
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

jgharston wrote:
Sat Sep 11, 2021 1:59 pm
"sound" as in:
TINT n,m -> VDU 23,17,n,m,0,0,0,0,0,0
OK, fair enough, I'd forgotten that TINT is VDU 23,17... (needless to say I don't support that in my BASICs, any more than I do TINT in this context).

What does POINT() return if the colour has been set using TINT? Does it return the full 14-bit value, or just the top 6-bits, or what? How do you read the screen colour back in a non-paletted RGB mode (in my BASICs I've borrowed the TINT keyword for that)?

So in my BASICs (in all modes except 7):

Code: Select all

      COLOUR 1,50,200,100 : REM Set RGB colour for palette entry 1
      GCOL 128 + 1 : REM Set colour 1 as graphics background
      CLG : REM Clear screen to graphics background colour
      PRINT POINT(0,0) : REM Prints '1' because that's the colour number
      PRINT ~TINT(0,0) : REM Prints 64C832 which is the RGB colour
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
BeebMaster
Posts: 4444
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by BeebMaster »

This is what I get, same setup as earlier:
scrn0.png
Don't think it's working, it's the same as doing COLOUR 129:CLG.
Image
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

Richard Russell wrote:
Sat Sep 11, 2021 6:21 pm
[What does POINT() return if the colour has been set using TINT? Does it return the full 14-bit value, or just the top 6-bits, or what? How do you read the screen colour back in a non-paletted RGB mode (in my BASICs I've borrowed the TINT keyword for that)?
POINT() and TINT() in ARM Basic call down to OS_ReadPoint:
https://www.riscosopen.org/wiki/documen ... _ReadPoint

As far as I can tell, the information on that page is correct.

i.e. in a 16-bpp and 32-bpp mode, TINT() always returns 0, and COLOUR() returns the 16-bit or 32-bit value directly from the frame buffer.

Dave
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

hoglet wrote:
Sat Sep 11, 2021 9:00 pm
POINT() and TINT() in ARM Basic call down to OS_ReadPoint:
https://www.riscosopen.org/wiki/documen ... _ReadPoint
Hmm. POINT() in BASIC can only return a single value (AFAIK) yet OS_ReadPoint returns three values:

Code: Select all

R2	Colour
R3	Tint
R4	-1 if point was off screen, else 0
Assuming that BASIC returns the value in R2 and discards R3 & R4, I'm still not entirely clear (in my total ignorance of RISC OS hardware) what the footnote If in a 16 or 32 bpp mode, this will return the 15 or 24 bit colour number in R2 and tint will be 0 actually means.

Superficially, it seems that this also makes it difficult to write a program that works equally well on a paletted and non-paletted display, a design decision which I find unfathomable.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

Richard Russell wrote:
Sat Sep 11, 2021 6:21 pm
What does POINT() return if the colour has been set using TINT? Does it return the full 14-bit value, or just the top 6-bits, or what? How do you read the screen colour back in a non-paletted RGB mode (in my BASICs I've borrowed the TINT keyword for that)?
POINT(x,y) returns the top 6 bits of the colour number, TINT(x,y) returns the following 8 bits of the colour number.

So COLOUR POINT(x,y) TINT TINT(x,y) or COLOUR POINT(x,y):TINT TINT(x,y) sets the "pen" to the full colour of a point,
and GCOL POINT(x,y) TINT TINT(x,y) sets the graphics "pen". Yes, it looks confusing with the multiple TINTs (and I missed one out just now!), but it's just the same concept as MODE MODE.

It's logical enough, but I agree I've never really liked the way Acorn manipulated non-paletted 256 and 256+ colour displays.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

jgharston wrote:
Sun Sep 12, 2021 10:58 am
Richard Russell wrote:
Sat Sep 11, 2021 6:21 pm
What does POINT() return if the colour has been set using TINT? Does it return the full 14-bit value, or just the top 6-bits, or what? How do you read the screen colour back in a non-paletted RGB mode (in my BASICs I've borrowed the TINT keyword for that)?
POINT(x,y) returns the top 6 bits of the colour number, TINT(x,y) returns the following 8 bits of the colour number.

So COLOUR POINT(x,y) TINT TINT(x,y) or COLOUR POINT(x,y):TINT TINT(x,y) sets the "pen" to the full colour of a point,
and GCOL POINT(x,y) TINT TINT(x,y) sets the graphics "pen". Yes, it looks confusing with the multiple TINTs (and I missed one out just now!), but it's just the same concept as MODE MODE.

It's logical enough, but I agree I've never really liked the way Acorn manipulated non-paletted 256 and 256+ colour displays.
POINT() and TINT() do not appear to test the "point outside screen" flag returned from OS_ReadPoint which on other platforms results in -1 being returned.

The RISC OS Open website is timing out for me, but from memory, up to 256 colours is fairly straightforward:

Code: Select all

            POINT and
             COLOUR   TINT
  2 colours  l------c --------
  4 colours  l-----cc --------
 16 colours  l---cccc --------
256 colours  l-cccccc cc------

-=ignored on writing, zero on reading
But I can't remember how it goes for larger colour depths, and I think you have to bypass the VDU API.

16,384 colours could logically be:

Code: Select all

            POINT and
             COLOUR   TINT
16K colours  l-cccccc cccccccc

-=ignored on writing, zero on reading
but you run out of space for 32K, 64K, 16M colours.

I think what strikes me as odd about the Acorn method of handing large colour depths is that they stuck fast to implementation rather than function.

VDU 19,num,16,255,0,0 programs the palette to set that logical colour num to be displayed as red, but you can also read it as "I wish to draw with logical colour num and wish it to appear as red", and that /functionality/ could have been implemented for deep colours as "from now on, whenever logical colour num is used, it will use whatever deep physical colour is available that is the physical colour requested.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

jgharston wrote:
Sun Sep 12, 2021 12:12 pm
VDU 19,num,16,255,0,0 programs the palette to set that logical colour num to be displayed as red, but you can also read it as "I wish to draw with logical colour num and wish it to appear as red"
You could, but that would have been a breaking change had it been introduced later (e.g. at the RISC OS stage). For the sake of three extra bytes I'd prefer that it be expanded as VDU 19,num,16,r,g,b,18,0,num (or equivalently VDU 18,0,num,19,num,16,r,g,b) as I said earlier, then compatibility would have been retained. GCOL r,g,b could have been converted to that VDU sequence, with num set to a constant such as 1.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
hoglet
Posts: 10489
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by hoglet »

jgharston wrote:
Sun Sep 12, 2021 10:58 am
POINT(x,y) returns the top 6 bits of the colour number, TINT(x,y) returns the following 8 bits of the colour number.
That's only true in the 256 colour modes.

In 16M colour modes, POINT(x,y) returns the 24-bit colour value that was written to the frame buffer, and TINT(x,y) returns 0.

Dave
Soruk
Posts: 942
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Soruk »

Having just been pointed to this thread by hoglet on the Zoom call, it is worth noting that the >256 colour support in Matrix Brandy is likely quite buggy (and I see that it is returning tint values when it shouldn't be). This I will need to look into....

Edit: Fixed. Hopefully.
Matrix Brandy BASIC VI (work in progress)
User avatar
jgharston
Posts: 4512
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by jgharston »

hoglet wrote:
Sun Sep 12, 2021 6:13 pm
jgharston wrote:
Sun Sep 12, 2021 10:58 am
POINT(x,y) returns the top 6 bits of the colour number, TINT(x,y) returns the following 8 bits of the colour number.
That's only true in the 256 colour modes.
In 16M colour modes, POINT(x,y) returns the 24-bit colour value that was written to the frame buffer, and TINT(x,y) returns 0.
Yes, I was trying to track down what OS_ReadPoint returned in deep screen modes, but my connection to the updated documentation kept timing out.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

hoglet wrote:
Sun Sep 12, 2021 6:13 pm
In 16M colour modes, POINT(x,y) returns the 24-bit colour value that was written to the frame buffer, and TINT(x,y) returns 0.
In my BASICs, I try to achieve as much compatibility as possible between paletted (LUT) modes and true-colour (RGB) modes. So POINT() always returns a palette index (in an RGB mode it returns the palette entry closest to the RGB colour); similarly TINT() always returns the 24-bit colour.

Unless you are relying on palette animation (which only works in a hardware-paletted mode) or need more than 256 different colours on the screen at the same time (which only works in an RGB mode) programs should work without modification whichever type of display it is.

To me that was a no-brainer, I don't understand why anybody would think it is a good idea to introduce unnecessary incompatibility between different display modes.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
Soruk
Posts: 942
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Soruk »

Richard Russell wrote:
Wed Sep 15, 2021 1:00 pm
Unless you are relying on palette animation (which only works in a hardware-paletted mode) or need more than 256 different colours on the screen at the same time (which only works in an RGB mode) programs should work without modification whichever type of display it is.
I worked around this by, when putting the actual RRGGBB values into the frame buffer, the top 8 bits (usually for alpha, but as I've set up my frame buffer without transparency, these top 8 bits are completely ignored) contain the selected colour number on a <=256 colour mode. This is used, when the colour is changed with VDU19, the screen memory is searched and the colour can be replaced, without messing up when two colour numbers could be the same colour. The downside is that for large dimension screen modes, it can be quite slow (but for BBC-sized screens, it's more than fast enough).
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2471
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Richard Russell »

Soruk wrote:
Wed Sep 15, 2021 1:51 pm
the screen memory is searched and the colour can be replaced.
You and I have very different approaches. I certainly don't attempt to emulate a paletted display when the actual hardware isn't paletted, and since display modes on all modern PCs never are paletted (except, sometimes, when a Compatibility setting is enabled in Windows) in practice such modes simply aren't available any more in my BASICs.

This is a fundamental difference between an emulator (in your case of RISC OS) and an implementation of BBC BASIC for modern computing platforms. It's why in my BASICs you can use all the native capabilities of the display: proportional-spaced text, anti-aliased graphics, 3D graphics, shader graphics etc. but not palette animation.

Fortunately there is a market for both approaches! Your product has by far the larger uptake, because there are many more retro-computing enthusiasts who want to run existing BBC BASIC programs than there are people who want to use BBC BASIC to write new programs from scratch. I am not actually sure there are any active users of my BASICs, but there might still be a handful.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
Soruk
Posts: 942
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Question on colour/tint in 16bpp and 32bpp modes

Post by Soruk »

Richard Russell wrote:
Wed Sep 15, 2021 2:39 pm
I am not actually sure there are any active users of my BASICs, but there might still be a handful.
At the risk of straying a bit off-topic here, I'm pretty sure you also have an active userbase. Just look at those games that have been produced using BB4W/BBCSDL, and the development that took place on this forum for the Mode 7 graphics package Telepaint.
Matrix Brandy BASIC VI (work in progress)
Post Reply

Return to “32-bit acorn hardware”