Pi boot screen when using *Configure Mode

My Pi (running 5.21 RC14) is configured for 1280×1024 in CONFIG/TXT and *Configure Mode 32

During the boot sequence, the “RISCOS Pi” logo screen isn’t displayed, instead you get the old style full screen DOS style boot screen. However, the progress bar graphic still appears on the screen – part way hanging off the right side and extremely large.

Should the progress bar appear in this scenario? It doesn’t look like it should.

It certainly doesn’t sound like it should appear in that case! Unplugging BootFX should make it go away, although of course that doesn’t explain the underlying problem.

Are any modules unplugged? Type *UNPLUG to see and check whether BootFX is unplugged. Config/txt does not configure RISC OS, it configures the GPU.

Should the progress bar appear in this scenario?

No sounds like a putative answer but I can confirm that it does. The Pi does seem to assume 1920×1080 at start up. Ensuring that Boot$Progress* is unset in !Boot.Utils.BootRun gets rid of the bars but is not the best practice.

Unplugging BootFX should make it go away

Earlier defective answer deleted.

Correct answer. It certainly does, and as a bonus the startup banner also goes away.

BootFX is a different module to BootCommands.

BootFX is a different module to BootCommands.

Oops, cross-eyed moment there. Defective post will be corrected.

Related to this, why can’t you *Configure Mode or WimpMode to a MODE specifier? They’re both locked to MODE no’s.

Because there’s only one byte (or maybe even less?) assigned to it in CMOS. And (apart from the on the Pi) there won’t be any MDF loaded at the time the configured mode is evaluated – so a mode specifier would be useless.

Also note that (since RISC OS 3.5?) the *Configure Mode and *Configure WimpMode actually change the same value.

They’re both locked to MODE no’s.

*Configure Mode and *Configure WimpMode do the same thing – they write a mode number to CMOS RAM at offset +196.

And (apart from the on the Pi) there won’t be any MDF loaded at the time the configured mode is evaluated – so a mode specifier would be useless.

Would it be an idea for RISC OS to contain, internally, an MDF providing “standard” video timings for a selection of typical modern display devices from SVGA (800×600) upwards?

Looking at the CMOS RAM allocations, there seems to be a lot of locations lost to history. Or is some enterprising person working on bit-banging Econet via GPIO pins¹? ;-)

Averted. ☺ I’ve tweaked the WimpMode page.

¹ Liable to be slow? Heck, it ought to outpace Acorn’s FileStore!