Raspberry Pi B+: MODE has stopped working

Hi Folks — I just got my hands on the new Pi B+, and installed RISC OS on it. After configuring it to work with my monitor (a ViewSonic), I dropped into BASIC via the CLI and was able to set various MODEs (Teletext, etc.) just fine. But a day later (all I’d done in the meantime was write some trivial BASIC programs in !StrongEd and played with some of the bundled game programs) MODE commands seem to have stopped working: whatever MODE I specify I get the same results: a generic graphics mode (that looks like the old MODE 4 from the original Beeb text-wise, but which supports at 800 × 600 graphics with at least 256 colors).

I’ve tried MODE MODE, which once dropped me into something that looked like MODE 0, but once I tried to change modes again from there it’s the MODE 4 lookalike, and MODE MODE has done nothing but a CLS. I’ve tried configuring different monitor types and resolutions, but no joy.

Any thoughts? Should I just wipe the flash card and reinstall? Any advice much appreciated!

Cheers,

Stephen

Are you able to change to different resolutions from the desktop?

If not: What is your monitor type set to?

I recall a “quirk” that for some reason disabled the monitor definitions that I had set up¹, so it was reverting to a “safe” built in mode. I wonder if something similar is happening on your system?

¹ Never figured out what was wrong, I just made the settings file read only and locked, so whatever was messing with it…couldn’t.

Thanks for the reply! I can change different resolutions from the desktop (I currently have the monitor type set to “ViewSonic VA2012wSERIES” @ 1600 × 1200 with a color depth of 16 million.)

Cheers,

Stephen

Hmm — just to add, I was able to reproduce this by reimaging my boot SD card. After initially configuring the screen, I used F12 to get into the CLI, started basic, used a MODE 7 command, which worked. Attempting to exit directly from BASIC at this point went even worse however, with my getting a “something has upset Pinboard” warning, and a change in resolution. Restoring the screen config settings so I could see more than a small area of the workspace worked fine, but no more MODE 7 when I dropped into BASIC. Will reimage one more time to see if it’s just MODE 7, or any of the others.

Okay, indeed invoking a MODE is a one-shot deal, regardless of the MODE, e.g. MODE 32. Except, oddly enough, when I set the screen driver to AUTO: I was able to MODE 7 into a weird interlaced mode. An attempt to enter MODE 0 after that just hung my Pi!

S.

Did you install RC12a or Pico? I found issues with Pico, which seemed to disappear. For example it would abort if I used *SLOAD twice.

I installed RC12a.

Final note: I did some more testing and was able to duplicate this with another screen, but if I left the screen driver on the RaspPi-BuiltIn setting that a fresh install starts in (which is not offered again as an option once you select a monitor type in the screen config screen), all the MODE commands work fine, with either screen!

Cheers,

S.

There are several issues that you’re seeing here:

1. Whenever a CMOS reset occurs (for the Pi, this will basically be whenever you update the ROM image) the *LoadModeFile command in !Boot will get clobbered. But the *WimpMode command which follows it will remain. This causes two issues:
   1. The Wimp will be told to use a bad mode. The mode change will silently fail, but the Wimp will remember the mode anyway. This means that (unless you manually set the mode from within the desktop) the Wimp will never be able to restore the mode on return from a single-tasking app. This has been fixed in the latest development ROMs (Wimp 5.40 and above; although it’s still possible to confuse it by setting a valid mode and then loading a different MDF)
   2. There was also a mistake in the kernel’s definition for mode 7. So if you tried using that without an MDF loaded (or tried changing the monitor type to ‘auto’, IIRC) then you’d get a garbled display or a crash. This is also fixed in the latest development ROMs.
2. The RasPi-BuiltIn MDF contains definitions for all the numbered modes. This works because the Pi GPU is capable of scaling (almost) any mode we want in order to fit the screen, regardless of whether your monitor actually supports that resolution. However the MDFs that are supplied on the disc image were all originally designed for use with other hardware which isn’t capable of display scaling – so the monitor actually has to support the mode timings which are described in the MDF. And since modern hardware is generally a bit pants at low-resolution modes, that means many of the numbered modes aren’t supported. If you select a numbered mode which isn’t supported then the kernel will generally substitute it for mode 28 (640×480, 256 colour).
3. Also it’s worth pointing out that the Pi doesn’t support anything with under 256 colours, so many of the numbered modes will be substituted for different ones anyway (although I think the OS is smart enough to make sure the replacement is the same resolution where possible).

Ah, thanks very much for the explanation! I guess until the fixes percolate through from the development tree I’ll just stick with a install that uses RasPi-BuiltIn for single-tasking Apps, and use a second card for when I want to use Wimp apps. I appreciate you taking the time to spell out the complexities involved,

Cheers,

Stephen

Ah, thanks very much for the explanation! I guess until the fixes percolate through from the development tree

Technically ALL Pi versions are development so the difference is really whether any fixes have been added along with a number of new features. Obviously the RC candidate revisions have a bit more testing.

Whenever a CMOS reset occurs (for the Pi, this will basically be whenever you update the ROM image) the *LoadModeFile command in !Boot will get clobbered.

There is a lot packed into this seemingly innocuous statement….

Am I right in my understanding here:
(1) on the Pi the cmos settings are stored within the rom image itself;
(2)when a fresh rom is put into !Boot.Loader by the user it will therefore have the ‘default’ cmos settings;
(3)when a rom starts up, it somehow knows that it is being used for the first time and so seeks out the file $.!Boot.Choices.Boot.PreDesk.Configure.Monitor and adds a ‘|’ character to the first line
(4)altering a cmos setting (for example something relatively harmless like keyboard repeat rate) will cause the rom image to be updated (with the new cmos setting) but will not trample on the Configure.Monitor file?

Would a simple work around be to add a deliberately blank line to that file?

I had thought that it was only when a ‘vanilla’ boot structure on disc was encountered that the RO510Hook etc. bits were used to populate Boot.Choices etc.. Any chance of a fuller explanation please?

(3)when a rom starts up, it somehow knows that it is being used for the first time and so seeks out the file $.!Boot.Choices.Boot.PreDesk.Configure.Monitor and adds a ‘|’ character to the first line

Close… it’s actually the ClrMonitor utility in the boot sequence which zaps the LoadModeFile command, rather than the ROM itself.

For a fresh Pi ROM the CMOS reset is initiated because the CMOS checksum will be incorrect.

Would a simple work around be to add a deliberately blank line to that file?

It would have done with old versions of ClrMonitor, but when I fixed the Wimp to throw an error on bad *WimpMode commands I also had to fix ClrMonitor so that it clears both lines of the file (otherwise the boot sequence would stop halfway through with an error). So you’ll have to add two blank lines (or rather, two lines with ‘|’ in them) to avoid the contents being clobbered (if you have a completely empty line ClrMonitor will end up overwriting the newline character). Or make the file read-only.

I had thought that it was only when a ‘vanilla’ boot structure on disc was encountered that the RO510Hook etc. bits were used to populate Boot.Choices etc.. Any chance of a fuller explanation please?

On the Archimedes there were two CMOS bytes used for configuring the mode – one used for single-tasking stuff (which is the mode the OS would switch to when it displays the startup message and runs the boot sequence), and the configured wimp mode which is what the Wimp would switch into once it starts up. Resetting the CMOS would understandably reset both of these.

On the RiscPC the configuration file in the boot sequence was introduced, and the Wimp mode CMOS setting was retired (the *Configure entry is still recognised but it just maps onto the byte used for single-tasking stuff). However one of the main reasons you’d want to initiate a CMOS reset (at least with the Arc) would have been if you display wasn’t working – so Acorn decided to include the ClrMonitor utility in the boot sequence to make sure that the wimp mode still gets reset whenever the user resets their CMOS.

Unfortunately for the Pi the combination of the above-mentioned bugs and how the CMOS settings are stored in the ROM image means that you end up with a less than ideal user experience whenever you upgrade your ROM. Finding a different way of storing the CMOS settings (e.g. hardware CMOS or a separate file on the SD card) would solve the main issue, but I’m thinking it would also be good if we made the boot sequence auto-load Configure whenever it detects a CMOS reset, preferably with a message letting the user know what’s just happened.

(3)when a rom starts up, it somehow knows that it is being used for the first time and so seeks out the file $.!Boot.Choices.Boot.PreDesk.Configure.Monitor and adds a ‘|’ character to the first line

No quite true the first character (i.e. the L of Loadfile…) is changed to ‘|’ (i.e. |oadfile…)
Which can be very difficult to spot unless you know it happens, especially when a sanserif font are used.

Very helpful explanation, thanks.

As I understand it, the fundamental purpose of the cmos settings was to provide a home for things that could not be determined easily (or at all) in the boot sequence. For example boot file system and boot drive number. Also for things that were hardware like number of CD drives.

Adding a HAL and having hardware that has only USB for adding things and a GPU that introduces an extra layer of monitor scaling has made some things more logically determined in a configure file within the boot sequence.

I think a hierarchy of where CMOS settings are loaded from and where changed settings are stored would be a useful piece of documentation.

Is this precedence for reading correct?

Physical CMOS memory on the motherboard (Risc PC and Iyonix and earlier only, if checksum correct)
Physical CMOS widget (beagleboard/pandaboard only, if fitted and checksum)
File ‘CMOS’ on SD card (beagleboard/pandabord only, if present and checks)
cmos values stored within rom image (if checksum correct)
do a cmos reset (using default values stored within rom elsewhere)

Note CMOS on SD card only works if module SDCMOS is present in rom.

Writing precedence will be different as reading needs a sole source (obviuosly) but writing needs to write to all methods available and into boot structure (like ‘savecmos’ does)?