"Correct" Mode Change and RGB<>BGR detection for BASIC code ?

Following some discussion in the programmers newsgroup I want to raise some talk also here about what would be the most wise or correct way to change the screen mode in one’s single task BASIC code. And by most wise I mean to have it working basically on all devices (of course I know there’s no palette mode’s any more with OMAP5).

Especially since the arrival of the OMAP5 boards it’s not an easy task any more. A simple “MODE” command doesn’t work for e.g. setting mode to 800×600×32 Bit Colour. It displays an error like screen mode not available. A “OS_ScreenMode”,0,block with the necessary data and check of the mode flags works, but I’m not yet sure if that’s the holy grail. Any other ideas ?

Furthermore since OMAP5 (at least for me, as it’s no issue on RPI, Panda or Beagle) we need to know if RGB order is BGR so that your graphics code (once you are doing low level stuff with graphics…) knows in what order to write or read screen data. I guess for that the only option is to read that from the mode flags ? …and then use the desired code for RGB or BGR. Any other way around that ?

Especially since the arrival of the OMAP5 boards it’s not an easy task any more. A simple “MODE” command doesn’t work for e.g. setting mode to 800×600×32 Bit Colour. It displays an error like screen mode not available.

BASIC’s MODE command is certainly one of the things that hasn’t been touched yet – at the moment requesting a BPP of “16” will work if a 15bpp colour TBGR mode is available, and “32” will only work with a 32bpp colour TBGR mode is available. Considering that all the OS rendering routines support the new modes, I’m wondering whether the solution there would be to have it automatically pick the most compatible pixel format, similar to the way the display manager operates – e.g. selecting a BPP of 16 would actually try the following modes:

• 15bpp non-alpha modes (TBGR, TRGB)
• 16bpp modes (BGR, RGB)
• 15bpp alpha modes (ABGR, ARGB)
• And then the 12bpp modes (TBGR, TRGB, ABGR, ARGB)

And for a BPP of 32 it would try:

• All the 32bpp modes (TBGR, TRGB, ABGR, ARGB)
• All the packed 24bpp modes (BGR, RGB) (Although the OS doesn’t actually support these yet)

If software is directly accessing the screen or assuming that pixels are in the traditional format then this might cause some compatibility issues – but in theory we already suffer from those kinds of problems due to the way numbered modes are substituted for others (generally an equivalent-resolution 8bpp mode) if the requested mode isn’t available.

A “OS_ScreenMode”,0,block with the necessary data and check of the mode flags works, but I’m not yet sure if that’s the holy grail.

That’s probably the best approach for now.

If you want you can also enumerate the available screen modes and work out which pixel formats are available from that, but that’s a bit of a complex operation (both for you and the OS) since there’s no way of just getting the pixel formats that are supported for a specific resolution.

If we want, I think there are two things we could try to make mode selection easier:

• Add a way of having the OS automatically select a suitable pixel format (e.g. like the MODE proposal)
• Add a way of enumerating the pixel formats (and frame rates) that are available for a given resolution

Furthermore since OMAP5 (at least for me, as it’s no issue on RPI, Panda or Beagle) we need to know if RGB order is BGR so that your graphics code (once you are doing low level stuff with graphics…) knows in what order to write or read screen data. I guess for that the only option is to read that from the mode flags ? …and then use the desired code for RGB or BGR. Any other way around that ?

For writing to the screen, you can use ColourTrans_ReturnColourNumber to convert a &BBGGRR00 format colour to the right pixel value for the current mode. But it’s not the kind of thing you’d want to do on a per-pixel basis if you’re trying to render a full screen at a reasonable framerate :-) (e.g. I recently updated ArcEm to use that SWI, but it uses it to build a 4K entry lookup table which is used until the next mode change)

There’s no equivalent SWI for reading from the screen (there’s one for converting to a GCOL number, but that’s a bit useless and I’m not even sure it works correctly outside of 8bpp modes), so maybe that’s another thing we can improve.

BASIC’s MODE command is certainly one of the things that hasn’t been touched yet

Since version 1.06 (23-Aug-1993) I think you mean:

MODE <number>|<string> - now takes a numeric or a string parameter: 
  where the numeric parameter is greater than 255, it calls OS_ScreenMode; 
  where it is given a string parameter, it calls *WimpMode <string>, 
  see PRM-5 for more information about this string.  
As a function MODE gives the current screen mode, numeric or a pointer to a string.
MODE has been extended to take a pointer to a mode selector or a mode string. A mode 
  selector is passed to OS_ScreenMode, whereas a mode string is passed to *WimpMode. 
The result is that if a program changes screen mode using a mode string, 
  e.g. MODE "X800 Y600 C256 EX1 EY1", then when the program finishes that will be your 
  desktop mode.
It should also be noted that the C/G option in the mode string is implemented by 
  *WimpMode. Hence, MODE MODE will select a default palette mode for the given current 
  mode depth. This means that if a grey mode is selected by MODE "X800 Y600 G256 EX1 EX1" 
  then MODE MODE will revert back to the coloured palette.

Also version 1.26 (20-Apr-2001):

New syntax for MODE: MODE <width>,<height>,<bpp>[,<framerate>]
  Uses OS_ScreenMode 0, rather than *WimpMode. bpp may be 1,2,4,6,8,16
  or 32. 8 selects a full palette 256-colour mode, 6 an old-style one.
BASIC will now surrender application space if possible at certain
  moments: during SYS calls (as long as no string parameters are
  passed in), MODE changes, OSCLI and * commands. Also, it will not
  refuse requests to grow application space (although it will not
  expand into the extra space).
Application space is only surrendered if no library is INSTALLed,
  HIMEM is set to the top of BASIC's memory, and BASIC's memory extends
  to the top of the application slot.
This permits easy MODE changes etc outside the desktop. Note the
  effect that now outside the desktop, with screen memory at <300K and
  no free pool, MODE 28 will work, while VDU 22,28 will not. This
  restores some long lost BBC MOS behaviour.

More detail here – the BASIC manual still describes version 1.05 (either 1988 or 1992 depending which version of the manual you have, possibly plus an addendum dated April 1995).

I probably wasn’t clear enough; I was talking about the “MODE <width>,<height>,<bpp>[,<framerate>]” version, which hasn’t been updated to add any way of selecting the new screen modes.

“MODE <string>” can be used to select the new modes (since it just uses *WimpMode, which uses the new-ish OS_ScreenMode 15 and so supports the full mode string syntax), but since it uses *WimpMode it’s probably something best to avoid (a single tasking BASIC program shouldn’t be messing with the wimp mode! Why on earth did Acorn think that was a good idea?)