Screen MODEs on BB

Sorry if this has been covered before or is “obvious” to computer engineer types but I don’t understand why on my Beagleboard when I type, in BBC Basic, MODE 10, which was traditionally a 256 colour mode 160×256 pixel screen, a two-colour mode is subsituted.

I get the bit about resolution substitution (e.g. a 640×256 substituion for 320×256 when going into MODE 1 as it depends on your monitor file setup. But not the colour depth substitution.

Could anyone kindly supply (or point to) guidance?

Also I recall on the RiscPC you could use “Mode strings” such as MODE “X320 Y256 C16”. Is this method of selecting screen modes still supported?

thanks.

Could anyone kindly supply (or point to) guidance?

There is definitely something slightly funny going on, I’ve known about it for a while but haven’t found the time to investigate. If I select mode 28 on my BB I end up with mode 0 (I think), and mode 21 selects mode 28. If I use a different MDF it’s not an issue, so it must be something to do with how the OS decides if an MDF entry is a match for a numbered mode, and the process the kernel goes through when it fails to find a match.

Also I recall on the RiscPC you could use “Mode strings” such as MODE “X320 Y256 C16”. Is this method of selecting screen modes still supported?

Yes, that’s still supported.

Hi Jeffrey
|{background:#ddd}.Also I recall on the RiscPC you could use “Mode strings” such as MODE “X320 Y256 C16”. Is this method of selecting screen modes still supported?|

Hi Jeffrey
*BASIC
MODE “X320 Y256 C16”
gives a 256 colour screen mode of 160 chars by 128 chars. The resolution (1280×1024) corresponds to the 1280×1024 resolution in the Display setting, decreasing the resolution in the Display setting gives correspondingly smaller number of characters across and down the screen after issuing the MODE string. So:

1) To get the correct resolution outside of the desktop you have to manually alter the display setting inside the desktop – correct? Or is there a way of doing it without inconveniencing the user’s orignal settings in the desktop?

2) More worryingly it is selecting a 256 colour mode when I asked for a 16 colour one (C16)

Advice please.

Thanks.
Richard.

Not sure about the mode strings but over on the Armini support list Andrew Rawnsley has mentioned possible inclusion of “old school modes” in monitor definition files. Must admit it would be useful to be able to predict what resolution/colour depth you are going to get for a particular MODE number since from what you are saying they don’t seem to correspond to previous versions of RISC OS.

Look at this GetMonInfo
It create VESA-kompatible MDF for Beagle and Co.

Thanks Raik – unfortunately not much use here. Some of the settings in the MDF generated by !GetMonInfo result in my monitor flashing up an “out of range” message. At least with the current settings it will display a screen mode, even if it is of an unpredictable resolution/colour depth.

I’ve now fixed the bug that was stopping some modes from working properly on the BB (and PB). The fix should show up in tomorrow’s ROMs.

FWIW, the sequence RISC OS uses when it’s asked for a numbered mode is as follows:

1. If the requested colour depth isn’t supported by the hardware, substitute the mode number for a similar mode which is at a supported colour depth
2. Check the MDF for an entry at the right resolution, colour depth and framerate
3. Check the MDF for an entry at the right resolution & colour depth, any framerate
4. Check the MDF for 640×480×60Hz, 640×256×50Hz, 640×200×60Hz, 640×480 (any framerate), at the requested colour depth
5. If the checks above failed, repeat step 4 at 4bpp
6. If it still hasn’t found a valid mode, the kernel takes over and tries using mode 25, 26, 27 or 28 (depending on BPP), defaulting to mode 28 if the requested BPP isn’t available. The checks the kernel does here completely ignore the limitations of the graphics hardware, apart from which colour depths are supported. However, when it comes to actually setting the mode, it will still try looking it up in the MDF (using rules 2 & 3 above), and then default to the kernels built in list of mode timings if the MDF doesn’t contain a suitable entry.

The above rules will be slightly different depending on which monitor type you’ve got selected (e.g. it’ll default to mode 0 instead of 25/26/27/28 if monitor type 7 isn’t in use)

For non-numbered modes the process is a lot simpler – if the mode you ask for isn’t found (or isn’t supported) it will refuse to change mode.

So, long story short, as long as your MDF has an entry at the right resolution, and that entry doesn’t violate these rules which the OMAP video driver checks for, you should now get the right mode on your monitor.

Excellent, thank you Jeffrey. I have re-flashed my Beagleboard with the latest Rom image and all the MODEs seem to work now.