Have you installed the AnyMode module in Boot.Choices.Boot.PreDesk? From memory, once you’ve done that, you can simply open a Task Window and they type Wimpmode x1280 y768 C32k. I don’t know if the latest ROMs with EDID will work with RPCEmu. I can’t access a copy of RPCEmu at the moment, but there may also be an MDF somewhere in Boot.Resources.Configure.Monitors that will allow it as standard.

I believe ‘AnyMode’ has only ever worked on a Pi 1 which previously didn’t support mode timings. AIUI AnyMode provides no timings and relied on the GPU doing its own EDID. Recent Pi builds now support Mode timings (a very useful improvement!) unfortunately support for modes with no timings was removed. I hope it is reinstated soon.

The ROMs will work, but you won’t be able to get EDID from the “monitor” because the VIDC hardware doesn’t support reading EDID.

Recent Pi builds now support Mode timings (a very useful improvement!) unfortunately support for modes with no timings was removed. I hope it is reinstated soon.

If you want, you can switch back to the old behaviour by adding the string “disable_mode_changes” to cmdline/txt in the Loader partition (create the file if it doesn’t exist) and then rebooting.

Why do you want to see the feature reinstated? If we can get a better idea of how/why people were using AnyMode then that will help with planning future work, so that we can eventually arrive at a “best of both” solution.

I’m not sure exactly what this is about, but I’ve got “disable_mode_changes” so I can have my own defined modes beyond 1920×1200 – a whole range of them right up to 3840×2160 (at 24Hz), all working beautifully (but with the GPU clocking ~20% faster than spec, iirc).

One “creative resolution” is RISC OS’s own teletext emulation, which a few people might want to use by asthetic choice. Some transparent solution as an fallback if the monitor can’t deliver would be nice to have. In short, I agree with Steffen.

I’m not sure exactly what this is about, but I’ve got “disable_mode_changes” so I can have my own defined modes beyond 1920×1200 – a whole range of them right up to 3840×2160 (at 24Hz), all working beautifully (but with the GPU clocking ~20% faster than spec, iirc).

In your case, you could probably do without disable_mode_changes if you were able to construct an MDF (or custom EDID block) containing valid mode timings for all the modes you use. But the “if” is the key part here, since our current MDF authoring tool (MakeModes) is a bit outdated. At the least, it could do with extending to add support for generating timings using the GTF and CVT algorithms, so that you only need to specify the width+height+refresh rate.

If RISC OS were to one day include an automatic upscaler (with doubling for rectangular pixels) then happy days!

That’s basically what I was hinting at when I raised the question. AnyMode only works on the Pi and RPCEmu, and doesn’t take into account things like differing refresh rates or aspect ratios. A solution that’s built into the OS should be able to improve on that.

One “creative resolution” is RISC OS’s own teletext emulation, which a few people might want to use by asthetic choice. Some transparent solution as an fallback if the monitor can’t deliver would be nice to have.

In preparation for the arrival of EDID, I did make some improvements to the teletext emulation, to bring it closer to the flexibility offered by RISC OS Select. In particular, the OS will try a series of different fallback modes if you try selecting mode 7 but the custom 640×500 mode definition isn’t available. It’s not perfect (e.g. if you’re in a fallback mode then reading back the mode number won’t give a result of “7”) but it should work for the majority of cases.

We use a ‘no timings MDF’ for the pi-top display. I don’t think it supports EDID and there is no data sheet available or source code for the Linux driver (It was promised at the launch but they backtracked and would give us no information at all). From experience getting MakeModes to produce a usable MDF is time consuming and while the Pi’s GPU does such a good job it seems a waste of effort. Whilst I appreciate that having a way of supporting 99% of uses in the OS is the best, I’d hope that it would not be a lot of work to add a check for all timing are zero so “disable_mode_changes”. Some ‘users’ are are not up to fiddling with Loader partition files!

This mailing list message suggests that the Pi-Top does have EDID (which is what I would expect, since the Pi’s firmware is heavily reliant on EDID) but it may only list one mode (1366×768). And 1366×768 isn’t a mode that works with RISC OS yet (due to framebuffer pitch/padding issues within RISC OS, much like those mentioned on the linked message).

Long-term I suspect the best behaviour for the Pi-Top would be for the OS to drive the LCD at 1366×768 and rely on the GPU to scale the RISC OS screen output, much like disable_mode_changes. It’s just a question of finding a suitable way to represent that within the MDF/EDID system.

In preparation for the arrival of EDID, I did make some improvements to the teletext emulation, to bring it closer to the flexibility offered by RISC OS Select. In particular, the OS will try a series of different fallback modes if you try selecting mode 7 but the custom 640×500 mode definition isn’t available. It’s not perfect (e.g. if you’re in a fallback mode then reading back the mode number won’t give a result of “7”) but it should work for the majority of cases.

I have underestimated you again, sir. :D In my defense, I only recently started using my RISC OS Pi again.
On a slightly unrelated note: Could the numerical form of BASIC’s MODE command be extended to set other aspects of a mode like colour order and eigen values?

Can I confirm something… I have my Pi hardwired to 1280×1024 via mode selection in the config.txt file. The Pi itself then has a variety of modes available, none of them with timings, and when RISC OS goes into a different mode, the GPU just rescales it to 1280×1024.
As such, my Pi outputs a solid video signal with no problems, unlike the Beagle xM that really doesn’t behave nicely with the HDMI to VGA adaptor.

Question is – is it still possible to keep this behaviour? To have the GPU run at a fixed size and fake everything else by scaling?

I suspect “disable_mode_changes” (=1?) is it, but then what will RISC OS do with an MDF that has dummy values for everything except the size?

Question is – is it still possible to keep this behaviour? To have the GPU run at a fixed size and fake everything else by scaling?

Yes.

I suspect “disable_mode_changes” (=1?) is it

Just disable_mode_changes.

but then what will RISC OS do with an MDF that has dummy values for everything except the size?

It will accept it as valid.

disable_mode_changes isn’t a GPU thing; cmdline/txt is intended to be used for specifying Linux kernel boot args. RISC OS isn’t Linux, but we can still use the feature as an easy way of getting arbitrary configuration parameters into the HAL/OS.

I wasn’t aware it existed. I write them manually in StrongEd (used to do it in Zap), have done for about twenty years. It’s a lot easier now that everything’s dummy values except the size!

I have my Pi hardwired to 1280×1024 via mode selection in the config.txt file. The Pi itself then has a variety of modes available, none of them with timings, and when RISC OS goes into a different mode, the GPU just rescales it to 1280×1024.

What is the best option for 4 colour modes.
I think the Ti manages 4 colours.

Correct, Titanium supports 2bpp (4 colours) on the primary head. In the desktop this is offered as 4 greys by Display Manager (because the mouse pointer is overlaid in hardware, it’s still its usual blue colour), but can be reprogrammed to any 4 colours using the palette too.

A hex number. But the number can’t possibly answer any question you have because it’s merely saying how many bytes are left in the buffer, and since the buffer contains the names of the modes in the currently loaded MDF, and that varies depending on which monitor is plugged in, that hex number means nothing.

Can you rephrase the question to ask what it is you’d like an answer to? If you have pre-sales technical questions feel free to contact Elesar directly, or pose the question on a Titanium related thread here (it’ll be lost in the RPCEmu forum).