Booting in 'Beeb style'

Trying to force my RPI to boot into old ‘Beeb style’ I made the following:
- *Opt 4,0
- *Unplug bootfx
- *Configure Language 1
One step separates me from the goal. This is the screen mode.
I would like Mode 28, but have 1920×1080.
Among items that *Status command outputs, I see ‘Mode 28’ and ‘WimpMode 28’, but really I have 1920×1080 anyway.
BASIC says this is the ‘-79645552’ Mode.
If I change the mode in BASIC to 28 then all is OK, I have what I ask and keep Mode 28 after QUIT (but not after reset).
I suspect, 1920×1080 is a GPU inheritance and RISC OS accepts this ‘as is’, because nobody did ask to change. How can I ask RISC OS about it? StarCommand?

It is easy to set the config/txt file to tell the GPU to select a particular screen mode and ignore the EDID. That is separate from the mode that RISC OS may select – each is decided independently. The GPU then stretches what RISC OS produces to appear as if it were what the GPU had decided.

Well, config.txt, let it be one of the solutions. But, is it possible to reconfigure the GPU with RISC OS remedies? Not a joke you said ‘…RISC OS may select…’ ? :) Something proof against reset and, maybe, suitable for scripts wanted.

No.

I see, various RISC OS versions behave differently concerning CMOS option ‘Mode’. RC12 keeps the ‘Auto’ value and if I change it then after reset or power-on it will be ‘Auto’ anyway. RC12a does not change my setting, but ignores it and behaves as though the setting would be ‘Auto’. RISC OS Pico is really guided by this option and sets the ordered screen mode.

None of the solutions within RISC OS reconfigures the GPU. RISC OS decides its own screen mode (not very consistently, as you describe) and the GPU stretches or shrinks RISC OS output into the resolution it decided upon from a combination of EDID and config.txt.

How it has always decided. What you have to remember though is that whatever RISC OS produces is not sent to the monitor (as on previous hardware). It is sent to the GPU. The GPU has independently decided what it will be sending to the monitor and just stretches/shrinks what it gets from RISC OS and sends it on to the monitor.

The monitor then decides whether what it has received is in its native resolution. If not, then it does another stretch/shrink itself (LCD screens are fixed resolution).

When RISC OS asks the GPU to create the buffer in the RAM (the virtual screen) for placement of the picture, it requests the desirable width and height of this virtual screen. Depending on the mode these virtual values can coincide or not coincide with physical values. Where RISC OS gets these values from?

RISC OS has a configured screen resolution. That’s where it gets its configured screen resolution from. Try looking at *STATUS and in !Boot.

An ‘infinite loop’ in discussion can easily be caused by posting any stuff without bearing in mind everything posted above, from very first post of topic. I watched Status many times and I look it all the time, but it does not bring me happiness. Concerning !Boot… This topic is about starting OS without !Boot (*Opt 4,0 – see first post).

Concerning !Boot… This topic is about starting OS without !Boot (*Opt 4,0 – see first post).

However if you look in !Boot.Choices.Boot.Predesk.Configure.Monitor you would find commands like:
WimpMode X1280 Y730 C256 F60

Chris was (wrongly) treating you like an experienced RO user of many years and expecting you to know where such things live. This was wrong on two counts:
The first that you’ve used RO for years,
and the second that someone who has used RO for years actually knows where all the obscure startup bits live.

!Boot in some section is a good place to look for startup information and configuration choices will be in the sub-directory !Boot.choices (mostly)

The main question that interested me and caused this topic – it is incorrect (in my opinion) operation of Mode option during the launch of OS (without !Boot).
As already seems, there are no opinions on the matter. Allow me to express my one (just came to mind).
I remembered a conversation about the malfunction Boot / NoBoot on RPi. A wise man then suggested that the reason is in the keyboard (Can not well-timed poll of modifier keys for a reason ‘Keyboard not present. Autobooting….’) And now, when I see at startup as my values of some options are automatically reset to the ‘Auto’, it seems like something very similar to…
For options ‘Mode’, ‘MonitorType’ and ‘Sync’ start modifier keys also exist… And the same problem (‘Keyboard not present’) is also possible in this case. Isn’t it?
Opinions are welcome. If not – the topic can be finished.

Keyboard not present. Autobooting….

Ignore it, it’s a legacy of old hardware operation.
Old hardware had bus mouse or PC mouse connections, new hardware has only USB mouse connections and until the USB module is fully started nothing on USB is detected.

For “old hardware” read equipment designed and built over 10 years ago at best and upto 28 years ago.

Ignore it, it’s a legacy of old hardware operation.

Perhaps the message ought to be suppressed on systems that don’t support old-style keyboard handling?

BTW – quick question for Jeffrey etc – how does one build a RISC OS image and have it boot up without the long list of module init messages? I’m guessing there is some sort of DEBUG|RELEASE flag or similar?

Perhaps the message ought to be suppressed on systems that don’t support old-style keyboard handling?

I have a feeling I may have said the same, the other year.

What ROM image are you using? Or, more specifically, what version of BCMVideo is present? Prior to version 0.22 it would always override the mode on startup to 1920×1080. In 0.22 and beyond (as present in the Pico image) it only overrides the mode if the configured mode (as set in CMOS) is ‘auto’. So for example, on today’s ROM image I can do the following in order to boot into BASIC in mode 7 (as per the Pico image):

*opt 4,0
*configure language 13
*configure mode 7
*unplug bootfx

(Although I admit I had to do the *opt again after rebooting – but that was probably just a typo on my part)

BTW – quick question for Jeffrey etc – how does one build a RISC OS image and have it boot up without the long list of module init messages? I’m guessing there is some sort of DEBUG|RELEASE flag or similar?

Yep. In Kernel.hdr.Options, set DebugROMInit to false (and DebugHALTX as well if you want to cut out some of the other spam)

Is this test – possible to change in a previous ROM :-
ie by doing a search and replace in !Zap?

Jeffrey Lee: