BASIC Mode Selection (on Titanium)

I’m wondering if I’m missing something. A BASIC program recently came my way which opened with the line

MODE 1920, 1080, 32 : OFF

and which, when run on a Titanium that natively operates in “X1920 Y1080 C16M LTRGB F60” on the desktop, reported “Screen mode not available”. I’ve returned this evening to look at it in more detail, and couldn’t see the problem. So I did some more digging, and found that

MODE "X1920 Y1080 C16M"

also failed with “Screen mode not available”, but if I explicitly demand B and R swapping with

MODE "X1920 Y1080 C16M LTRGB"

then it’s happy, and the program runs.

I can sort-of understand the mode string¹, but when writing MODE 1920, 1080, 32 one would like to expect that it would worry about the RGB/BGR order for itself since that form of MODE has no option for specifying it? Otherwise, BASIC programs on a system with B and R swapped pretty much have to use the mode string version of MODE and remember to specify “LTRGB”? This would seem to make writing “portable” BASIC graphics demos fairly hard, unless one sticks to the current screen mode².

Have I missed something? This is on BASIC 1.81, RISC OS 5.28.

¹ Although a mode string without the L parameter feels as if it should be more intelligent, too.

² Which is another argument altogether.

https://www.riscosopen.org/forum/forums/1/topics/16050

When you’re using OS routines and don’t need to care whether it’s RGB or BGR, this is all an unnecessary complication

Thanks; I’d obviously missed that. It seems… sub-optimal to add a nice new, user-friendly MODE <x>, <y>, <bpp> way to select modes to BASIC, then immediately render it unusable… :)

It’s not a major problem for me, because it just adds another reason to recommend the use of MODE MODE and then reading back the screen dimensions in a tutorial that I was writing. I just wanted to make sure that I understood the problem correctly first – the original reason for recommending it was screen resolutions, and this wasn’t even on the horizon.

then immediately render it unusable… :)

Yeah, it’s a bit duh.

However, source is available. It ought to be a few extra lines to try RGB if the normal (BGR) fails, before giving up. Submit a patch, then it’ll “magically work”. ;-)

Though, to be honest, this should be fixed in the OS. If the user doesn’t explicitly specify a mode type using the mode flags, then OS_ScreenMode ought to set the mode if a definition exists, regardless of the byte ordering.

I would imagine a lot of stuff that uses regular OS calls to draw to the screen wouldn’t care which way around the screen was set up.
My Virus game, for instance, uses the exact same code for drawing, but selecting the mode means jumping through a hoop to specifically try the RGB mode if the regular (BGR) version failed.

it just adds another reason to recommend the use of MODE MODE and then reading back the screen dimensions in a tutorial that I was writing

Edit: I’m talking crap as usual. ;-)

I think the main reason for MODE MODE these days is to check that you got what you actually asked for. Newer video hardware is a lot less capable at the eccentric old modes than the VIDC.
For example, both MODE 0 and MODE 12 on my Pi2 actually arrive at MODE 15 (as the lowest number of colours is 256 indexed), and MODE 13 gives a pointer to a mode definition of 640×480 with eigen values of 2 in both directions.

MODE 13… It looks like something is going wrong here though – you’d have thought that the screen resolution would be something like 320×240 (rather than the expected 320×256); however it appears from a simple test as if the pixels are all small sized, and the top right corner of the display is 2544,1916 (but only settable in groups of 4?).

To put this into context, the upper right in MODE 28 appears to be 1279,959. So I’m not sure what’s up with MODE 13’s co-ordinates.

I’m not using AnyMode, BTW.

I think the main reason for MODE MODE these days is to check that you got what you actually asked for.

I’m not sure that I follow? The point of MODE MODE, from the BBC BASIC Reference Manual, is to reset the values of the current mode: that is, “change mode” to a mode that you already know works because you’re already in it.

In the context I’m interested in for what I’m writing, we’re not looking for a specific screen mode. All we want is a mode, which we can then determine the dimensions of. After that, it’s geometric shapes all the way – and there’s no difference between

MODE 1920, 1080, 32
RECTANGLE FILL 384, 108, 1152, 864

or

MODE MODE
width% = (VDU 11 + 1) << VDU 4
height% = (VDU 12 + 1) << VDU 5
RECTANGLE FILL width% / 10, height% / 10, width% * 0.8, height% * 0.8

except that the latter should work in any available mode – albeit with different proportions.

(I’ve just written that off the top of my head, so I’m quite prepared to accept that the maths is wrong.)

Oh, and if you do colour selection using

GCOL red%, green%, blue%

then the actual colours available don’t matter either, AFAIK.

I’m not sure that I follow? The point of MODE MODE

Yeah… uh… sorry… “insufficient tea” error. Now that my brain is working, I see that it’s setting MODE to itself, not trying to read MODE. <facepalm>

except that the latter should work in any available mode – albeit with different proportions.

Works fine in what passes for MODE 13, MODE 15, and MODE 28 on the Pi2. It’s slightly squished in MODE15, but then the entire mode is. 13 and 28 work fine.

Not seen VDU actually used like that before. That’s pretty nifty. A lot simpler than messing around with calling the ReadVduVars SWI.

Not seen VDU actually used like that before. That’s pretty nifty.

I only found it in the Reference Manual yesterday; prior to that, I was using SYS "OS_ReadModeVariable". I think I was aware of it, but not enough to remember that it existed when I needed to use it.

Apparently it’s been there since the Iyonix was launched…

SWI is the native means of making system calls it should logically be more direct

As BASIC keywords are the native way of writing programs in BASIC, it is logically more correct to have VDU as a function able to read these variables.

using the BBC MOS compatibility methods.

Rubbish, it’s nothing to do with the MOS. It was added circa Iyonix (April 2001).

https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASIC/-/commit/a7c3ba42066cd9a3c2f3bc88691ee71f18c8e864

Not seen VDU actually used like that before. That’s pretty nifty. A lot simpler than messing around with calling the ReadVduVars SWI.

As well as vduvalue%=VDU(number%) you might like VDUS basenumber% TO [vduvalue%]^ to read a sequence of VDU/MODE variables, such as a text window VDUS 123 TO left%,bottom%,right%,left%. ;-)

SYS “OS_ReadModeVariable” versus cryptic VDU use – Hmmm. One tells you what it’s for and the other does not.

So, for all the humans it’s SYS “OS_ReadModeVariable” then.

SYS “OS_ReadModeVariable” versus cryptic VDU use

Although the SYS version takes a couple of subroutines, an understanding how to tease out processor flags, and eight or so lines to do

Width% = (VDU 11 + 1) << VDU 4

so I know which I’ll be going with.

Although the SYS version takes a couple of subroutines, an understanding how to tease out processor flags, and eight or so lines to do

There are numerous Perl one-liners that do a lot while being massively cryptic too

VDU as a function. Nearly 20 rears old, BASIC 1.26, 16th Mar 2001.

Documentation :-

>HELP VDU
VDU <number>[;|][,<number>[;|]]: list of values to be sent to vdu.
, only - 8 bits.
; 16 bits.
| 8 bytes of zeroes.
As a function VDU x gives the value of the specified vdu variable.
>

HowTo :-

REM >ReadModeVar
FOR X%=0 TO 11
  SYS "OS_ReadModeVariable",-1,X% TO ,,value1%
  value2% = VDU X%
  PRINT X%,value1%,value2%
NEXT
END

A little archeology, see s/Factor

VDUFN   STR     R14,[SP,#-4]!
        BL      FACTOR
        BL      INTEGZ
        LDR     R14,[SP],#4
        MOV     R1,#-1
        MOV     R2,#0
        STMFD   SP!,{R0-R2}
        MOV     R0,SP
        ADD     R1,SP,#8
        SWI     READVDUVARIABLES
        LDR     IACC,[R1]
        ADD     SP,SP,#12
        B       SINSTK

VDU as a function looks to be a veneer calling OS_ReadModeVariable

VDU as a function looks to be a veneer calling OS_ReadModeVariable

As many BASIC keywords are veneers to SWI calls.

SYS “OS_ReadModeVariable” versus cryptic VDU use – Hmmm. One tells you what it’s for and the other does not.

Overloading keywords is hardly unheard of, eg RETURN. One advantage of VDU here, made clear by the Steve F code, is that it is a function.

I think I have this right, the OS_ReadModeVariable code is duplicated for OS_ReadVduVariables, so you takes your pick. However, the former can be used for any mode, the latter only the current mode, and the latter can be used to read several values at once.

With the speed of the machines we are using now, hiding SYS calls behind PROC|FN calls seems entirely reasonable. For me it is just that the keyword looks so much neater. ;-)

There are numerous Perl one-liners that do a lot while being massively cryptic too

If you’re not comfortable with the

Width% = (VDU(11) + 1) << VDU(4)

line, then by all means break it up. An alternative, which is getting closer to the SWI-based version, is

DEF FNread_mode_dimension(pixelvar%, eigenvar%)
LOCAL pixels%, eigenvalue%

pixels% = VDU(pixelvar%)
eigenvalue% = VDU(eigenvar%)

=(pixels% + 1) << eigenvalue%

followed by

Width% = FNread_mode_dimension(11, 4)

That seems like a lot of padding to me, but if you prefer it, that’s fine. However, using OS_ReadModeVariable is comprehensively cryptic:

DEF FNread_mode_dimension(pixelvar%, eigenvar%)
LOCAL pixels%, eigenvalue%, flags%

SYS "OS_ReadModeVariable", -1, pixelvar% TO ,,pixels% ;flags%
IF flags% AND 2 THEN =-1

SYS "OS_ReadModeVariable", -1, eigenvar% TO ,,eigenvalue% ;flags%
IF flags% AND 2 THEN =-1

=(pixels% + 1) << eigenvalue%

I remain unconvinced that this is clearer than using VDU() to read the values in some form or other.

(All code off the top of my head and untested.)

Did this update make it into the boot structure update for older RISC OS systems? If so it could be a useful way to do some things, just takes a few minutes to wrap the brain around using VDU as a value reference instead of to issue VDU commands.

Yes, as I mentioned recently on another thread, if you have a pre-RISC OS 5 machine you just download System Resources from the Miscellaneous downloads page and follow the instructions in the ReadMe to merge it, then add a one-line Obey file to Choices:Boot.PreDesk containing the following line:

RMEnsure BASIC 1.75 RMLoad System:Modules.BASIC

With just BASIC I have used this to get dimensions of the current mode:

DEFPROCthis_mode_size(RETURN width%,RETURN height%)
 !&8200=4:!&8204=5:!&8208=11:!&820C=12:!&8210=-1
 SYS"OS_ReadVduVariables",&8200,&8200
 width% =!&8208+1<<!&8200
 height%=!&820C+1<<!&8204
ENDPROC

Edit: Corrected to add list terminator.

Using the input buffer should always be safe.

Never say ‘always’, although in over 30 years it has not changed. ;-)

For safety you would use a DIMmed buffer or some other construction.