COLOUR statement

Hi!
The old BASIC manual had three uses for the statement COLOUR. There are six of them in the new one!
But are they all applicable to the RISC OS Pi?
I tried the sixth option and it didn’t work.
Program:
10 COLOUR 4, 255, 255, 255
20 COLOUR 4
30 PRINT “Qwerty”
I expected line 10 to make color 4 white, on line 20 I choose this color, but somehow it’s green!
I do not understand something?

I suspect that behaviour may only work in 16 colour modes or something?

For 256 colours, it wants COLOUR with TINT because how it works is weird, and in 16M colour modes…

Personally, I find it best to completely ignore colour numbers, and just specify the desired colour directly:

COLOUR 255,255,0
PRINT "This is in YELLOW!"
COLOUR 0,255,255
PRINT "This is in CYAN!"

Ah, here we go.

I looked at the BASIC source, and it looked like it was using VDU 19 to set the colours if four parameters were given, or calling the PaletteV vector if five parameters. A quick peek at the updated BASIC reference manual shows this to be the case (bottom of p257 (265 real)).

PRM-5a specifies on page 5a-114 (128 real) that for 16bpp and 32bpp modes: VDU 19 should not be used in these modes.

We probably ought to file this as a BASIC bug in this case? ;-)

That said, I never got it to work correctly in anything other than MODE 12 (16 colours).

EDIT: Yup. Just tested with Archie and RISC OS 3.11. Works fine in MODE 12, but fails in MODE 15 (256 colours, gives me a murky green).

Given the freaky way that BASIC can look when using the command line single tasking in a 16M mode (brown prompt/output, your typed input in bright red), I suspect that the older VDU style colour handling may be really messed up with any screen mode more capable than a BBC Micro….unless it is LineEditor failing at mucking with the colours?

My MODE 12 also gives green color.
According to PRMs MODE 12 should be 80×32 / 640×256 / 16colors.
It’s actually 90×50 / 720×400, how to check the color mode – I don’t know. PRINT MODE in BASIC gives 805790644
______________________________________
Raspberry Pi B+ RISC OS Pi 5.28

My MODE 12 also gives green color.

That’s to be expected.

The old modes relate to the original Acorn machines (from the A310 to the RiscPC).

The newer ones may have limitations in their capabilities. For example, the Pi cannot do any mode with less than 256 colours, so if you ask for an old mode with fewer colours, you’ll get a 256 colour mode instead.

As for the resolution, again modern devices won’t be putting out interlaced 2:4 pixel aspect modes on HDMI (or, probably, at all) so you’ll either get an error about the mode not existing, or the closest that does exist depending upon your setup.

That big value that PRINT MODE returned is a mode specifier block. Assign it to a variable (say, A%) and then A%!4 will be the width, A%!8 will be the height, and A%!12 will be the colour depth (2=16col, 3=256col, 5=16Mcol).

My !GraphTask does a pretty good job of running programs which use the old 2,4,16 and 256 colour numbered modes.

The problem is more about impossibility to create an ‘old program’ using ‘new hardware’.

Perhaps the author of ‘Aemulor’ could bring out the low colours handling out into a separate module – for working in 32bit mode.

[Edit]
Updated info on history of ‘Aemulor’ on site
sendiri.co.uk

Vladimir I don’t know if you’ve tried this, but ADFFS lets you choose modes 9 and 12 on the Pi so you can try COLOUR 0 – 15, although it doesn’t appear to do flashing colours yet. You don’t need a disc image – just double-click on it so it’s on the iconbar, and then go into BASIC as normal.

Also if you’ve not seen this bit of the BASIC manual, you might like reading the Teletext section. That is supported natively on the Pi (beautifully in my opinion), and will definitely give you that “old program on new hardware” feel!

Sorry, but briefly, in general terms, what is ADFFS?

It’s an application, written by Jon Abbott, that lets you play tonnes of ’90s RISC OS games under RISC OS 5 on your Pi.

Apparently, something like an Archimedes emulator …Isn’t it?

How to play old games,I read here. That seems as quite difficult. Is ADFFS easier to use?

The HW is able to do 16 color modes

Citation needed.

The documentation for framebuffer_depth specifies 8bpp, 16bpp, 24bpp, or 32bpp. The 8bpp will be using a palette, the others will be direct RGB values – RGB565, RGB888, and ARGB.

You could fake it by simply defining a smaller palette and only using 2, 4, 8, or 16 of the colours, but the thing here is that it is likely to require a lot of untangling between the RISC OS colour depth and the framebuffer.

With 8bpp, it’s pretty much a 1:1. Sure, the VIDC colours are weird with all that colour and tint stuff, however the end result is 256 distinct values, which can be set up as the palette to use. It doesn’t matter how they were originally calculated, only that they’re unique values.

Apparently, something like an Archimedes emulator …Isn’t it?

I guess it makes RISC OS 5 look like an Archimedes to the games.

How to play old games,I read here. That seems as quite difficult. Is ADFFS easier to use?

I’ve not tried Elite; hopefully someone else can answer – I use my Pi through VNC so not good for doing that sort of thing.

Well. Enough for now. Thanks for answers Julie.